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ISO Connectionless-—Mode Network Protocol 


Status of This Memo 


This RFC suggests an addressing scheme for use with the ISO 
Connectionless Network Protocol (CLNP) in the Internet. This is a 
solution to one of the problems inherent in the use of "ISO-grams" in 
the Internet. This RFC suggests a proposed protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Distribution of this memo is unlimited. 


This memo is a revision of RFC 986. Changes were made in order to 
allow the addressing used in the CLNP in the Internet to be 
potentially useful for routing in the context of new inter- and 
intra-domain routing protocols, and in the context of large numbers 
of networks and routing domains. The addressing scheme proposed in 
this RFC allows individual routing domains to make use of internal 
routing algorithms utilizing a variety of addressing formats, while 
still providing for a common addressing approach for use by inter- 
domain routing. These features are important due to the rapid growth 
currently being experienced in the Internet. 


1. Objectives 


The data communications protocols currently emerging out of the 
international standardization efforts warrant an early integration 
into the existing extensive Internet network infrastructure. The two 
possible approaches are a top-down one, where ISO applications like 
FTAM, X.400 and VIP are integrated on top of the transport function 
of the IP protocol suite, or a bottom-up approach where the whole ISO 
tower gets integrated without merging the two suites. The bottom-up 
approach may make use of the fact that the ISO-CLNP and the IP are 
very similar in function. This implies that it is reasonable to 
implement a multiprotocol function in some or all of the Internet 
gateways (potentially including part or all of the Internet 
environment). The result would be that at least large portions of 
the Internet, in particular the backbones, can become usable for full 
implementations of the ISO protocol stack. 


A major problem with this approach is that there are open issues with 
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regard to the ISO addressing within the CLNP. In particular, the ISO 
network layer addressing standard allows a great deal of flexibility 
in the assignment of addresses, and a particular address format must 
be chosen. A further problem is the need for implementation and 
integration of routing facilities for the ISO-compatible subset of 
the Internet environment. 


This paper proposed to use addresses which are considerably more 
flexible than the addresses used in the current IP Internet 
environment. This flexibility is necessary in order to allow some 
routing domains to base their internal routing protocol on addresses 
derived from the current IP addresses, to allow other routing domains 
to base routing on addresses in accordance to the intra-domain 
routing protocol being developed by ANSI and ISO [6], and to allow 
generality for a future inter-domain routing protocol. 


The addressing scheme proposed here makes use of the concept of 
"routing domains" as used in ANSI and ISO. This concept is similar 
to, but not identical with, the concept of "Autonomous System" used 
in the Internet. Routing domains include a combination of gateways, 
networks, and end systems (not just gateways), and routing domain 
boundaries may be used to define associated access control and policy 
routing constraints. Like autonomous systems, routing domains may be 
assumed to be topologically contiguous. There is no a priori reason 
why routing domains assigned for use with the ISO IP need to have any 
particular relation with existing autonomous systems which have been 
assigned for use with the IP. The assignment of specific routing 
domain identifiers is an "assigned numbers" function which is 
necessary for use of the ISO IP in the Internet, but is beyond the 
scope of this document. 


It is expected that this addressing scheme will be appropriate for 
long term use with the ISO IP in the Internet. However, it is also 
expected that in the long term, the Internet will be interconnected 
with other routing domains making use of other schemes, such as 
addresses assigned to commercial internets through ANSI, and 
addresses assigned by national standards organizations in other 
countries. This implies that, in the long term, gateways in the 
Internet will need to be able to route datagrams to destinations in 
other routing domains not conforming to the addressing format 
proposed here. This is discussed in greater detail in section 6. 


2. Introduction 
The CLNP is documented in [1], but for matters of completeness the 


following illustration of the CLNP header is included here as Figure 
t; 
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The addressing part of the header is the subject of this RFC, 
respectively. 
and [3], with this document 


the source and the destination address, 


addresses are generally discussed in [2] 
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presenting a specific method for addressing in the Internet 


environment, 
addresses. 
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3- 


Addresses for Use in the Internet 


This section describes the addresses used to address NSAPs in the 
Internet. 


The appropriate Authority and Format Identifier (AFI) is one octet in 
length. It specifies an ISO-6523-ICD assignment, and also that the 
Domain Specific Part (DSP) of the address is based on binary. The 
AFI octet uses the value "47". The ISO-6523-ICD format is used to 
emphasize that this is an administrative assignment. The usage of an 
ISO DCC (Data Country Code) would be possible, but could be 
misleading due to the fairly far spread geographical extent of the 
Internet. 


As required by the ISO addressing standard, the next two octets of 
the address, in this case, specify the Initial Domain Identifier. 
This two octet value is the International Code Designator (ICD) 
assigned to the Internet, "0006". 


The remainder of the NSAP address is the Domain Specific Part (DSP). 
This is assigned by the Internet administration, which is considered 
to be an addressing domain. Note that there is no particular 
relationship required between addressing domains and routing domains. 
In this case, although the Internet is considered to be a single 
addressing domain, it is expected that it will consist of multiple 
routing domains. 


The DSP of the address specifies a one octet version number, a two 
octet global area number, a two octet routing domain number, a 
variable length padding field, a variable length IGP specific part, 
and a one octet selector field. 


The version number is provided to allow for future extensions, and 
must contain the value "02". 


The global area number and routing domain number are provided to 
allow for inter-domain routing. Initially, the global area number is 
reserved and must be set to zero. The routing domain number may be 
set to the routing domain number of any gateway by which the 
associated host address is directly reachable. 


The IGP specific part of the address may contain whatever addressing 
format is used in the routing domain. Two particular formats are 
expected to be used initially, and are presented in section 4. 
Padding is used so that the entire address will always be 20 octets 
in length. 


The selector field performs the same function as the user protocol 
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This is necessary because the ISO protocol 


considers identification of the user protocol to be an addressing 


issue, 


and therefore does not allow for the user protocol to be 


specified in the protocol header independently from the address. 


The assignment of specific routing domain identifiers to defined 


routing domains, 
field, 


Internet [4]. 


scope of this document. 


In summary, 


Connectionless Protocol, 
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Global Area 
Number 


Routing 


Domain 


Octet 


20 


ISO IP address structure 


and the assignment of values for use in the selector 
are functions for the Assigned Numbers authority for the 
The specific values to be used are outside of the 


a source or destination address within the ISO 
when used in the Internet, 


looks as follows: 
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The Authority and Format Identifier (AFI) is "47" (BCD). The Initial 
Domain Identifier (IDI) consists of the International Code Designator 
(ICD) assigned to the Internet, and must contain the value "0006". 
The Version Number must contain the value "02". The Global Area 
Number must contains the value "00". The Padding field is of 
variable length, but must contain the value zero. 


4. Specific Values for use with the IGP specific field 


In general, a particular routing domain may specify any addressing 
scheme for use with the IGP specific part of the address, up to 11 
octets in length (consistent with the maximum address length of 20 
octets). However, it is expected that initially addresses used in 
this field will consist of either the current IP addresses, or 
addresses conformant with those specified in the draft ANSI proposal 
for intra-domain routing. 


For end systems which are members of routing domains using the IP 
addresses for internal routing, the addresses will look as follows: 
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ISO IP Address with Encoded DoD IP Address 


For end systems which are members of routing domains using the 
address format specified in the draft ANSI proposal for intra-domain 


routing [6], 
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the addresses will look as follows: 
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+------------------------ + 
| AFI | 
+------------------------ + 
| IDI / ICD | 
+-- --+ 
| (specifies DOD Internet) | 
+------------------------ + 
| Version Number | 
+------------------------ + 
| Global Area | 
+--- ---+ 
| Number | 
+------------------------ + 
| Routing | 
+--- ---+ 
| Domain | 
+------------------------ + 
| | 
+--- ---+ 
| Padding | 
+--- ---+ 
| | 
+------------------------ + 
| | 
+-—- LOC-AREA ---+ 
| | 
+------------------------ + 
| | 
ID 
| | 
4+------------------------ + 
| Selector | 
+------------------------ + 
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Octet 


19 


20 


Figure 4: ISO IP Address with Encoded ANSI-format Address 


5. Devices Attached to PDNs 


Otherwise isolated end systems, 
only indirectly via public data networks, 


which are attached to the Internet 
and simple LANs which are 


Similarly attached only via Public Data Networks, may make use of a 
separate address format based on their X.121 address. Such addresses 


may, for example, 


use the ISO-X.121 address format discussed in [3]. 


These addresses will need to be handled for routing purposes in much 
the same way as addresses in routing domains which have been 
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interconnected to the Internet, but which use other address formats, 
such as those specified by national standards bodies. 


6. Migration to Future Routing Protocols 


Initially, routing of ISO datagrams in the Internet may make use of 
the first 8 octets of the address (AFI, ICD, version, global area 
number, and routing domain number) as a flat field identifying the 
routing domain. This implies that if EGP is initially used for 
routing between routing domains, a new version of EGP may be required 
to carry 8 octet routing domain numbers instead of 3 octet network 
numbers. 


There are currently several efforts underway to determine the 
requirements for inter-autonomous system routing, and to define a new 
protocol. One of the requirements of inter-autonomous system routing 
is the need to be able to deal with a very large Internet. It is 
anticipated that during the lifetime of the addressing scheme 
described in this RFC the number of networks in the Internet will 
grow to the point where it is no longer feasible for any gateway to 
maintain separate routes to every network in the Internet. Allowing 
inter-domain routing to be done by routing domain number instead of 
network number is therefore a necessary step in the long term. 


It is difficult to anticipate the rate at which the number of routing 
domains may grow. For example, during a period of time in which the 
number of networks grows by a factor of 100, it is not clear whether 
the number of routing domains may also be expected to grow by a 
factor of 100, or by some lesser amount. It is possible that the 
number of routing domains will also grow to a point where it is not 
feasible for a single gateway to maintain separate routes to each. 

In order to prepare for this eventuality, we have provided for a 
"global area" field. 


In the long term, it will be necessary for gateways to route to 
destinations which are in routing domains utilizing other addressing 
formats, specified by other organizations such as ANSI, ECMA, etc. 

In this case, it will not be possible to ensure that the first 8 
octets of the address specifies the routing domain. In the long 
term, it will therefore be necessary to route based on variable 
length routing domain identifiers. It may be assumed that future 
inter-domain routing protocols will allow for specification of either 
(1) an address mask, specifying which part of an address is relevant 
for specifying those destinations which are reachable via a 
particular domain; or (2) a length field, specifying how many leading 


octets in a particular address are relevant. Specification of the 
details of such a routing protocol is beyond the scope of this 
document. 
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